Complex integrated circuits (ICs) can be designed using various levels of abstraction. Using a hardware description language (HDL), circuits can be designed at the gate level, the register transfer level (RTL), and higher logical levels. When designing a circuit using an HDL, the designer describes the behavior of a system in terms of signals that are generated and propagated from one set of registers to another set of registers through various cells of combinatorial logic. HDLs provide a rich set of constructs to describe the functionality of each module. Cells may be combined and augmented to form even higher-level modules.
System-level circuit design may rely on reuse of previously created designs that have been provided either from within an enterprise or from a commercial provider. Such logic blocks include, for example, adders, multipliers, filters, and other arithmetic and digital signal processing (DSP) functions from which circuit designs can be readily constructed. The logic blocks may further include memories and storage elements. The engineering community sometimes refers to these previously created cells as “IP (intellectual property) cells,” “cores,” or “IP cores,” and such terms may be used interchangeably herein.
System-level design tools allow users to create complex circuit designs by instantiating and connecting various design objects (e.g., IP cells) from a library on a design canvas. These design objects can be arranged and connected programmatically (e.g., using TCL code) or interactively in a graphical manner. The use of pre-developed IP cells permits faster design cycles by eliminating the redesign of circuits. Thus, using cells from a library may reduce design costs. Such pre-developed IP cells may be available for purchase by parties who desire the functionality provided by the core.
IP cells include a circuit design in the form of source code or a netlist that may be used in implementing the design in a programmable IC, such as a field programmable gate array (FPGA). IP Cells may be parameterizable. That is, the designer may specify values of parameters to tailor certain core functionality according to the designer's needs.
An IP cell may be integrated into a design by instantiating the code or netlist. The cell is then placed and routed along with the rest of the design to provide the desired functionality. Connection of IP cells to form a larger design, however, may not be a simple task. For example, different logic cores included in a design may be configured to communicate using different communication protocols. Likewise, each communication protocol may include a large number of configuration settings such as clock frequency, data width, etc. Designers not familiar with the topology of a certain system architecture may find it difficult figuring out which IP cells are required, and how to connect and configure the IP cells in the circuit design. Further, even if designers know how to arrange cells for a selected topology, connection and configuration of cells can be a lengthy and burdensome task. Connecting an IP cell that offers an interface is often not as straight forward as defining an association between the source interface and the destination interface. For instance, clocks and resets may need to be correctly connected. Moreover, additional arbitration logic may be required to be included to provide a communication interface between cells using incompatible communication protocols. Manual configurations of the cell parameters and interface logic can be a time-consuming process.
Some system-level design tools may provide design assistance in the form of a design template and/or configurable IP cells. Design templates include a prearranged configuration of some basic IP according to a particular topology. Packaging a subsystem as a design template allows users to begin with a pre-canned design. However, templates are static designs that are not configurable. IP cells, in contrast, provide configurability. However, the level of configurability is limited by the fact that a configurable IP cell cannot manipulate other objects in a circuit design. As a result, the IP cell would be unable to utilize resources already claimed by other parts of the user's design (e.g., debug Module or clocking resources). Further, graphical user interfaces (GUIs) used for configuration of an IP cell become quite complicated as the number of configurable options increases.
Some other system-level design tools may provide limited design assistance in the form of design wizards. Wizards are configurable templates that provide a system view. Wizards may provide a number of auto-configuration functions. However, to reduce complexity of the wizard, assistance is limited to very specific scenarios, such as when the user starts with a blank canvas before any decisions have been made. Once a user changes the configuration of a system, the wizard cannot be used to perform additional auto-configuration tasks. This forces users to make all configuration decisions for a system in commencing the design process. This can be a problem if a designer is initially unaware of all functional requirements of the system. Furthermore, if the end-user is not the original creator of the design that is being worked on (i.e., a partially completed design), design assistance may not be available.